VPC内のIPアドレスを効率的に管理するVPC IP Address Managerが発表されました #reinvent

プール計画が重要です

AWS re:Invent 2021

#Amazon VPC

#AWS

坂巻一義

2021.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2021にてAmazon VPC IP Address Managerが発表されました。

こちらのサービスを利用することで、VPC内のIPアドレスを効率的に管理できるようになりそうです。概要を紹介しつつ、実際に触れてみたいと思います。

概要

AWSワークロードで利用するIPアドレスの管理、および利用状況等が監視できるサービスになります。コンソールからIPアドレスの利用状況の確認や、VPCへのIPアドレス割り当てを自動で行えるため、スプレッドシート等で行っていたIPアドレスの管理等が不要になります。

料金は、IPAMで管理されるアクティブなIPアドレスごとに時間料金が発生します。アクティブなIPアドレスとは、EC2やENIなどのリソースに割り当てられたIPアドレスとして定義されています。

時間料金： $ 0.00027（東京リージョン）

例えば、VPCに/16のCIDR（65536IP）を割り当て、EC2で5000IPアドレス使用していた場合、月額は以下のようになります。

5000（アクティブIP） x 30（日） x 24（時間） x $0.00027（時間料金）= $ 972（月額）

詳細は以下が参考になります。

やってみた

今回は単一のAWSアカウントにて、IPAMを利用しVPCにアドレスを割り当ててみたいと思います。

service-linked role作成

IPAMはservice-linked roleを使用して、リソースに関連付けられたCIDRの管理を行います。ここでは、AWS CLIよりservice-linked roleを作成します。 ^*1

$ aws iam create-service-linked-role \
--aws-service-name ipam.amazonaws.com
{
    "Role": {
        "Path": "/aws-service-role/ipam.amazonaws.com/",
        "RoleName": "AWSServiceRoleForIPAM",
        "RoleId": "AROAVWTKLCOCHDNQGZALF",
        "Arn": "arn:aws:iam::xxxxxxxxxxxxx:role/aws-service-role/ipam.amazonaws.com/AWSServiceRoleForIPAM",
        "CreateDate": "2021-12-02T03:20:53+00:00",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Action": [
                        "sts:AssumeRole"
                    ],
                    "Effect": "Allow",
                    "Principal": {
                        "Service": [
                            "ipam.amazonaws.com"
                        ]
                    }
                }
            ]
        }
    }
}

IPAMにおけるservice-linked roleの詳細については、以下が参考になります。

IPAM作成

コンソールよりIPAMを作成します。「データレプリケーションを許可」にチェックを入れ、名前を付与し運用リージョンを選択します。

IPAMが作成されると、1つのプライベートスコープと1つのパブリックスコープが作成されます。

スコープはIPAMにおけるの最上位の概念となり、IPアドレスの重複を防ぎます。スコープ内でプール（管理するIPアドレス範囲）を作成して利用します。

なお、デフォルトではリージョンごとに作成可能なIPAMは1つとなっていますので、複数作成する場合はクォータの調整が必要です。

プール計画

今回は以下の構成で、プールを作成していきたい思います。プールは後から追加可能で、最大10階層まで作成できるようです。

aw-pool（トップレベルのプール） … 192.0.0.0/8
└── ap-northeast-1-pool（リージョナルプール） … 192.0.0.0/12
    └── test-pool（開発プール） … 192.0.0.0/14
      └── VPCの割り当て … 192.0.0.0/16

プール計画については、以下が参考になります。

トップレベルのプール作成

トップレベルで管理するCIDRをプールに設定します。トップレベルのため、ソースプールは指定せず、CIDRを設定しました。

Create a top-level pool - Amazon Virtual Private Cloud

リージョナルプール作成

上記プール計画の通り、トップレベルのプール配下にリージョンナルプールを作成します。ソースプールにトップレベルのプールを指定し、CIDRを設定しました。

開発プール作成

上記プール計画の通り、リージョンナルプール配下に開発プールを作成します。こちらは、今回、最下層となるプールです。ソースプールにリージョンナルプールを指定し、CIDRを設定しました。 ^*2ここでは、ネットマスク長にルールを設けてみました。（最小/16、最大/24）

これで計画どおりの構成でプールを作成できました。

VPCへの割り当て

IPAMから割当を選択してVPCを作成しました。

開発プールでネットマスク長を設定していたので、ネットマスクは指定の範囲から選択しました。

以下、VPCが作成できました。

Allocate CIDRs - Amazon Virtual Private Cloud

プールの詳細画面

作成したVPCでEC2を起動し、開発プールの詳細画面を確認してみました。プールの割当状況や、利用可能なIPなどを確認することができました。

リソースの状況も確認することが可能です。

以上となります。

今回のプール構成で実際に運用していく場合は、以下のように開発プールが増えていくことになると思います。

▲ 重複も防ぐ

最後に

今回は、単一のAWSアカウントを使用してやってみましたが、マルチアカウントでの利用や、organizationと統合することも可能です。本番で利用する際は、管理するCIDR、用途にあわせ、プール計画が重要になりそうです。スプレッドシートでのIP管理に負荷を感じていたり、大規模ネットワークを管理する際は利用を検討してみてはいかがでしょうか。

参考

Network Address Management and Auditing at Scale with Amazon VPC IP Address Manager | AWS News Blog

脚注

本検証はコンソールからおこなっていましたが、今回の利用においてコンソールから作成するタイミングがなく、自動で作成されている様子もありませんでした。それにより、IPAMによるリソースの自動検出が行えなかったため、AWS CLIにて作成しました。 ↩
プール作成時に自動インポートの設定を「Don't allow」にしてしまったので、プール作成後に設定を更新しました。 ↩